Over the past year or so various people have been automating kernel builds with the aim of both setting the standard that things should build reliably and using the resulting builds for automated testing. This has been having good results, it s especially nice to compare the results for older stable kernel builds with current ones and notice how much happier everything is. One of the challenges with doing this is that for good coverage you really need to include allmodconfig or allyesconfig builds to ensure coverage of as much kernel code as possible but that s fairly resource intensive given the size of the kernel, especially when you want to cover several architectures. It s also fairly important to get prompt results, development trees are changing all the time and the longer the gap between a problem appearing and it being identified the more likely the report is to be redundant. Since I was looking at my own setup and I know of several people who ve done similar benchmarking I thought I d publish some ballpark numbers for from scratch allmodconfig builds on a single architecture:

i7-4770 with SSD	20 minutes
linode 2048	1.25 hours
EC2 m3.medium	1.5 hours
EC2 c3.large	2 hours
Cubietruck with SSD	20 hours
Intel Celeron N2940	1.75 hours

All with the number of tasks spawned by make set to the number of execution threads the system has and no speedups from anything like ccache. I may keep this updated in future with further results. Obviously there s tradeoffs beyond the time, especially for someone like me doing this at home with their own resources my desktop is substantially faster than anything else I ve tried but I m also using it interactively for my work, it s not easily accessible when not at home and the fans spin up during builds while EC2 starts to cost noticeable money to use as you add more builds.

Internet of Things seems to be trendy these days, people like the shiny apps for controlling things and typically there are claims that the devices will perform better than their predecessors by offloading things to the cloud but this makes some people worry that there are potential security issues and it s not always clear that internet usage is actually delivering benefits over something local. One of the more widely deployed applications is smart thermostats for central heating which is something I ve been playing with. I m using Tado, there s also at least Nest and Hive who do similar things, all relying on being connected to the internet for operation. The main thing I ve noticed has been that the temperature regulation in my flat is better, my previous thermostat allowed the temperature to vary by a couple of degrees around the target temperature in winter which got noticeable, with this the temperature generally seems to vary by a fraction of a degree at most. That does use the internet connection to get the temperature outside, though I m fairly sure that most of this is just a better algorithm (the thermostat monitors how quickly the flat heats up when heating and uses this when to turn off rather than waiting for the temperature to hit the target then seeing it rise further as the radiators cool down) and performance would still be substantially improved without it. The other thing that these systems deliver which does benefit much more from the internet connection is that it s easy to control them remotely. This in turn makes it a lot easier to do things like turn the heating off when it s not needed you can do it remotely, and you can turn the heating back on without being in the flat so that you don t need to remember to turn it off before you leave or come home to a cold building. The smarter ones do this automatically based on location detection from smartphones so you don t need to think about it. For example, when I started this post this I was sitting in a coffee shop so the heating had been turned off based on me taking my phone with me and as a result the temperature gone had down a bit. By the time I got home the flat was back up to normal temperature all without any meaningful intervention or visible difference on my part. This is particularly attractive for me given that I work from home I can t easily set a schedule to turn the heating off during the day like someone who works in an office so the heating would be on a lot of the time. Tado and Nest will to varying extents try to do this automatically, I don t know about Hive. The Tado one at least works very well, I can t speak to the others. I ve not had a bill for a full winter yet but I m fairly sure looking at the meter that between the two features I m saving a substantial amount of energy (and hence money and/or the environment depending on what you care about) and I m also seeing a more constant temperature within the flat, my guess would be that most of the saving is coming from the heating being turned off when I leave the flat. For me at least this means that having the thermostat internet connected is worthwhile.

I recently got a CubieTruck with a terabyte SSD to use as a general always on server. This being an ARM board rather than a PC (with a rather nice form factor it s basically the same size as a SSD) you d normally expect a blog post about it to include instructions for kernels and patches and so on but with these systems and current Debian testing there s no need Debian works out of the box (including our standard kernel) on it, the instructions worked easily and I now have a new machine sitting quietly in the corner serving away. Sadly it being a dual core A7 it s not got the grunt to replace my kernel build test system, an ARM allmodconfig takes eleven and a bit hours as opposed to a little less than twenty minutes on my desktop (which does draw well over an order of magnitude more power doing it), but otherwise you d never notice the difference when using the system. The upshot of all this is that actually there s no real adventure at all; for systems like these where the system vendors and the communities around them are doing the right things and working well with upstream things just work as you d expect with minimal effort. The one thing that s noticeably different from installing on a PC and really could do with improving is that instead of being shipped as part of the board the boot firmware has to be written to a SD card, something that could be addressed as easily as simply shipping a suitably programmed SD card in the box even without any other modification of the hardware, though on board flash would be even nicer.

An issue which I always find depressing but sadly unsurprising in discussions of process with software is the frequent disregard for human elements; indeed often the goal people have in creating process is to try to control and eliminate human elements. Little thought is given to what is going to motivate people to do what s asked and if they are going to follow it at all, or in the spirit it was intended. One example I ve seen several times is the idea that some engineers work on irrelevant things and that this can be fixed by requiring every commit to be tied to the project plan or a bug so off project work is obvious. This isn t really attacking the problem so much as putting a roadblock in place to try to avert it; the real problem is normally people not communicating about what they re doing and what s important but those problems are really hard to address. Sadly what tends to happen is that people work around the roadblock and cause some collateral damage; for example devaluing the bug tracker by referencing irrelevant bugs or creating meaningless bugs solely to allow commits, while continuing to behave like they did originally. This is often worse than the original situation. This sort of issue is one of the things I appreciate most about working on Linux there s quite a bit of process but because of the way it has been evolved the incentives are usually right to make sure they are followed in the spirit in which they were intended. For example the patch submission process is essentially just best practices for making sure changes go to people who care in a form which makes it easy for them to work with it; there is a bunch of tooling around it which built on those practices (and in turn influenced the practices) but it all comes back to that basic thing of getting attention for changes and making them easy to work with. As a result people mostly do the right thing (or close enough) so everything runs smoothly. The trick is to remember to standardize and write things down when it s needed notice the good practice and spread its adoption. The key difference here seems to be if process is viewed as something to solve problems for people or if it is viewed as a way to solve problems with people. If the problem is with the people then the view starts off negative and it s perhaps unsurprising that there is little consideration of how they will react. Sometimes it s not so much that a problem is seen with people as that the people doing don t have any real interest in the process (write only timesheets often bear no relation to reality for example) but there is an assumption that they are going to just do what they re asked (but instead they for example don t fill in their time sheets or don t provide accurate information). The end result is the same, their needs don t get considered and their actions end up being counterproductive. Starting to avoid these problems is fairly straightforward take a step back and consider why the people expected to carry out the process are going to want to do so. How does it help them? How will they see it helping others? Generally what s in it for them? If these are difficult questions to answer then there may be a problem it is likely people will ignore the process or do it badly without a lot of active enforcement, but perhaps that s OK for the situation. Beware of using metrics to provide incentives, metrics are gameable and that game can cause problems without care. But do think about people; making software is all about people.

A few months ago I started a new job at Linaro as the technical lead for the Linaro Stable Kernel I just posted a brief thing what I m up to now over on the Linaro blog.

Linux v3.6 was another quiet release for ASoC with just a single notable framework feature being merged:

• Added the ability to add and remove DAPM paths dynamically, mostly for reparenting on clock changes.
• New machine drivers for Marvell Brownstone, ST-Ericsson Ux500 and ttc-dkp.
• New CPU drivers for Blackfin BF6xx SPORTs in I2S mode, Marvell MMP, Synopsis Designware I2S controllers, SPEAr DMA, S/PDIF
• New CODEC drivers for Dialog DA732x, ST STA529, ST-Ericsson AB8500, TI Isabelle Wolfson Microelectronics WM5102

Yesterday when I got in from work I got my second letter in as many months through from BT saying that my account was being closed as my landline was being transferred to another provider. This was the first I d heard of this and it causes a cancellation charge so I called to complain; the first time I did this they said they couldn t tell me anything about who the line had been transferred to. They did tell me that there was no equivalent of PAC or MAC for landlines and that the only thing stopping this happening is the two week delay in implementing. This time BT felt able to tell me that the line had been transferred to Orange so I phoned Orange. Orange told me that the phone number had indeed been transferred to them in the name of someone else. They also said that they had no intention of attempting to carry out any authentication that lines being transferred to them are owned by the person they re being transferred to I explicitly asked them if anyone could just do this for any phone number and they confirmed that this is indeed the case. BT claim they can t block transfers for regulatory reasons; Orange claim this is possible and that I should just do that. I ve asked Orange to put a note on the account (which was the best they claimed they could do) and complained to OFCOM (who won t really talk to me without a formal escalation from the phone providers) but none of this really helps given the gaping security holes in the system. You really should need more information than just the phone number itself to transfer a number. On the slightly bright side I still appear to have phone service; presumably currently paid for by whoever is initiating the transfers.

Linux 3.6, which was released earlier today, saw continuing improvements in the factoring out of common code in the API lots of new features making drivers smaller and easier to write!

• Initial framework support for GPIO controlled enable signals, saving a bunch of code in drivers.
• Move fixed regulator enable time and voltage mapping table specifications to data.
• Used some of the recent framework enhancements to make voltage change notifications more useful, passing the voltage in as an argument to the notification.
• New drivers for Maxim MAX77686, TI LP872x and LP8788, Samsung S2MPS11, Wolfson Arizona microphone supplies and LDOs

Linux 3.6 was a very quiet release for regmap:

• Support for buses and devices specifying their endianness, providing some performance improvements for MMIO devices.
• Support for wake IRQs in regmap-irq.

I will be speaking at ELC-E in Barcelona this year, with a talk entitled regmap: The Power of Subsystems and Abstractions. I look forward to seeing some of you at the conference, perhaps even in the audience!

The big news for ASoC in 3.5 is the first two changes here which are pretty major features for the subsystem:

• Dynamic PCM support, allowing support for SoCs with internal routing through components with tight sequencing and formatting constraints within their internal paths or where there are multiple components connected with CPU managed DMA controllers inside the SoC.
• Greatly improved support for direct digital links between off-SoC devices, providing a much simpler way of connecting things like digital basebands to CODECs.
• Much more fine grained and robust locking, cleaning up some of the confusion that crept in with multi-component.
• CPU support for nVidia Tegra 30 I2S and audio hub controllers and ST-Ericsson MSP I2S controllers
• New CODEC drivers for Cirrus CS42L52, Freescale MC13783, LAPIS Semiconductor ML26124 and Texas Instruments LM49453.

There s been a bit of an increase in the amount of core work in version 3.5, regmap has enabled a lot of code to be factored out of drivers and into the core so drivers only need to provide data. This makes things a lot simpler to implement and review, it s hoped that it will also allow some framework enhancements for bulk operations in future.

• Helpers in the core for regulators using regmap, providing generic implementations of the enable and voltage selection operations which just need data to describe them in the drivers.
• Split out voltage mapping and voltage setting, allowing many more drivers to take advantage of the infrastructure for selectors.
• Support for Ricoh RC5T583, TI TPS62362, TI TPS62363, TI TPS65913, TI TWL6035, TI TWL6037

A surprisingly large series of updates for regmap this time, mostly due to all the work Stephen Warren has done to add support for MMIO buses. This wasn t really the target for the framework but it turns out that there s a reasonable number of cases where it s very helpful to use the register cache support to allow the register map to remain available while the device is suspended.

• A MMIO bus implementation, contributed by Stephen Warren. Currently this is limited to 32 bit systems and native endian registers.
• Support for naming register maps, mainly intended for MMIO devices with multiple register banks. This was also contributed by Stephen Warren.
• Support for register striding, again contributed by Stephen Warren and mainly intended for use with MMIO as typically the registers will be a fixed size but byte addressed.
• IRQ domain support for the generic regmap-irq controller, allowing devices to dynamically allocate interrupt ranges and support device tree bindings.
• A function dev_get_regmap() which allows frameworks using regmap to obtain the regmap for a device from the struct device, making life a little simpler for them.
• Updates to regmap-irq to support more chips (contributed by Graeme Gregory) and to use irqdomains.
• Support for devices with 24 bit register addresses.

BROWN Anne After a long illness bravely fought, Anne Margaret (n e Wilson), wife of Fred and mother to Mark, enthusiastic Scottish country dancer. Service to be held at Borders Crematorium, on Friday, May 25, 2012, at 11 am. Donations, if desired, to Marie Curie Cancer Support. Family flowers only.

This has been a fairly quiet release from a regulator point of view, the only real framework features added were devm support and a convenience helper for setting up fixed voltage regulators. Much more coming next time, though! The most noticeable thing in the changelog is that Axel Lin continued his relentless and generally awesome stream of fixes and cleanups.

• Managed (devm) versions of regulator_get() and regulator_bulk_get() simplifying error handling and resource management for drivers.
• Added a convenience interface for setting up fixed voltage regulators.
• Device tree support for TWL4030.
• New drivers for Freescale i.MX Anatop, Samsung S5M8767, TI TPS62360 and TPS65271 regulators.
• Removed BQ24022 in favour of the more generic gpio-regulator driver.

Things are really quieting down with the regmap API, while we re still seeing a trickle of new features coming in they re getting much smaller than they were.

• Support for padding between the register and the value when interacting with the device. This is required by some devices with high speed control interfaces in order to give the device time to get the values ready.
• Support for applying register updates to the device when restoring the register state. This is intended to be used to apply updates supplied by manufacturers for tuning the performance of the device (many of which are to undocumented registers which aren t otherwise covered). For want of a better term this feature is known as a patch.
• Support for two bit address, six bit value registers contributed by Wolfram Sang.
• Support for multi-register operations on cached registers contributed by Laxman Dewangan.
• Some additional diagnostics available via debugfs for the cache state.
• Support for syncing only part of the register cache, useful for devices with power domains or sub devices which can be reset independently.
• Stubs and parameter query functions intended to make it easier for other subsystems to build infrastructure on top of the regmap API.

plus the general bug fixes and tweaks you d expect.

Linux version 3.4 has been released. This was a very active release for ASoC in framework terms, in addition to the usual bug fixes and so on there were a large number of framework enhancements though most are fairly small or are laying the groundwork for more user visible features like dynamic PCM.

• Support for widgets not associated with a CODEC, an important part of the dynamic PCM framework.
• A library factoring out the common code shared by dmaengine based DMA drivers contributed by Lars-Peter Clausen. This will save a lot of code and make it much easier to deploy enhancements to dmaengine.
• Support for binary controls, used for providing runtime configuration of algorithm coefficients.
• A new DAPM widget type for regulator supplies allowing drivers for devices that can power down unused supplies while active to do without any per-driver code.
• DAPM widgets for DAIs, initially giving a speed boost for playback startup and shutdown and also the basis for CODEC<->CODEC DAI link support.
• Support for specifying the number of significant bits on audio interfaces, useful for allowing applications to know how much effort to put into generating data for a larger sample format.
• Support for a range of new TI reference boards including Panda, configured from platform data so new boards can be added without driver changes.
• Conversion of the FSI driver used on some SH processors to DMAEngine.
• New CODEC drivers for Maxim MAX9768 and Wolfson Microelectronics WM2200.

Linux 3.3 was released earlier this week. Aside from a few regmap related updates it was an extremely quiet release for the ASoC framework, the next few releases look like they will be much more active:

• Conversion of a number of CODEC drivers to use regmap directly. This is especially beneficial for drivers for devices which are part of MFDs as they can use a central cache for all operations and means that the process of factoring out the more complex register management code in ASoC can begin.
• As a result of the move of drivers to regmap the rbtree and LZO cache types have been removed, leaving only the the basic flat cache in ASoC. Drivers which need the more complex cache types should use regmap directly.
• Lots of cleanups and fixes from Axel Lin.
• New CODEC drivers for Cirrus CS42L73 and Realtek ALC5632.

Linux 3.3 was released today. This was the biggest release for the regulator API for quite some time thanks to the contribution of device tree bindings for the API by Rajendra Nayak, the first substantial framework update for a long time, but otherwise was fairly quiet:

• OpenFirmware bindings for the core and for the fixed regulator driver, contributed by Rajendra Nayak. Device tree bindings for the Freescale MC13892 PMIC were also added.
• A new regulator_bulk_force_disable() operation contributed by Donggeun Kim.
• A new driver for the Dialog DA9052 PMIC.

After the rush of new features in version 3.2 this has been a fairly quiet cycle for the regmap API, the main change being the wider usage by drivers. In terms of development of the subsystem itself this release sees: